home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.19980424-19980901 / 000317_news@newsmaster….columbia.edu _Thu Jul 30 12:05:36 1998.msg < prev    next >
Internet Message Format  |  1998-08-31  |  5KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id MAA16378
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Thu, 30 Jul 1998 12:05:36 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id MAA12010
  7.     for kermit.misc@watsun; Thu, 30 Jul 1998 12:05:35 -0400 (EDT)
  8. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Newsgroups: comp.unix.sco.misc,comp.protocols.kermit.misc
  11. Subject: Re: Xenix to 5.0.4 Data Transfer ? Stay with UUCP
  12. Date: 30 Jul 1998 16:05:33 GMT
  13. Organization: Columbia University
  14. Lines: 74
  15. Message-ID: <6pq5kd$i65$1@apakabar.cc.columbia.edu>
  16. References: <35bbffb0.3086687@news.ricochet.net> <35bb532d.1519852@news.ricochet.net> <Ewu3vs.1vy@bokonon.ussinc.com> <35c1f9d4.5908262@news.ricochet.net>
  17. NNTP-Posting-Host: watsun.cc.columbia.edu
  18. Xref: news.columbia.edu comp.unix.sco.misc:72130 comp.protocols.kermit.misc:9027
  19.  
  20. In article <35c1f9d4.5908262@news.ricochet.net>,
  21. Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:
  22. : On Wed, 29 Jul 1998 02:21:27 GMT, stephen@bokonon.ussinc.com
  23. : (Stephen M. Dunn) wrote:
  24. : 
  25. : >$Kermit, zmodem etc file transfer performance:
  26. : >$ http://www.columbia.edu/kermit/perf.html
  27. : >
  28. : >Is this the comparison that Chuck Forsberg (the guy who invented
  29. : >Zmodem) declared was garbage?
  30. : 
  31. There was a year-long debate over the Kermit benchmarks in
  32. 1993-94, which can be exhumed by anybody who keeps newsgroups that
  33. far back -- comp.dcom.modems was the main one, I think; maybe
  34. even comp.protocols.kermit, before it was split into .announce.
  35. and .misc.
  36.  
  37. In 1993, the general public believed the party line that Kermit
  38. protocol was instrinsically slow, and "should not be used except
  39. as a last resort".  This was stated in numerous sources,
  40. including telecom dictionaries and modem manuals (in fact, USR
  41. manuals still say this).  The benchmarks were to demonstrate
  42. that Kermit protocol was not intrinsically slow, and to show
  43. where the common misperceptions came from (primarily, minimal
  44. Kermit implementations in 3rd-party software packages).
  45.  
  46. : I went through this discussion with Chuck many years ago.  As I
  47. : vaguely recall, I wasn't all that convinced by his arguements
  48. : either.  I did a comparision for myself about 4 years ago and
  49. : found that with buffered UART's, proper tweaking and decent
  50. : modems, I can get almost identical performance out of large
  51. : packet UUCP, Zmodem and Kermit.
  52. :
  53. On a good connection.  On a poor connection, note that Kermit
  54. uses selective packet retransmission for recovery, while Zmodem
  55. rewinds to the point of error and starts over, which can be a
  56. rather large hit when there is a lot of latency in the connection.
  57.  
  58. : The difference is that Zmodem figured out the optimum packet
  59. : size without any configuration or tweaking while UUCP and
  60. : Kermit required parameter juggling.
  61. :
  62. Kermit is a much more pessimistic protocol than Zmodem.  By
  63. default, it *assumes* a poor connection -- lack of transparency,
  64. lack of effective flow control, etc, and therefore is able to
  65. usually work out-of-the-box on these connections, whereas Zmodem
  66. needs parameter juggling (window size, escaping, etc) to work at
  67. all on the same connections.  That's the tradeoff -- in a perfect
  68. world, of course, there would not need to be tradeoffs.
  69.  
  70. On the other hand, when you tell Kermit to use a particular
  71. packet size (any length up to 9024 is permitted), it treats that
  72. as a maximum.  Modern Kermits use a slow-start algorithm to test
  73. the waters, and when there are errors, uses exponential backoff
  74. with slow regrowth to recover performance in case the errors
  75. were transitory.  Both packet lengths and timeouts are totally
  76. dynamic and constantly adjust themselves to the connection.  You
  77. can watch these algorithms in action on the C-Kermit 6.0 or
  78. Kermit 95 fullscreen file-transfer display.
  79.  
  80. The point about the 24K binary file travelling at
  81. hyper-lightspeed is somewhat valid, and in retrospect I should
  82. have chosen a longer file (the point of this measurement was to
  83. dramatically illustrate the run-length compression feature).
  84. The results reported were as shown by the software timers, but
  85. in those days we had integer timers with 1-second granularity,
  86. and so for short transfers at high speeds, the rouding error
  87. could be rather significant.  Nowadays we have floating point
  88. timers and much-more accurate time and speed reports, e.g. in
  89. C-Kermit 6.1 (presently in Beta test):
  90.  
  91.   http://www.columbia.edu/kermit/ck61.html
  92.  
  93. - Frank